Use Case
Use Case-диаграммы и Use Case-сценарии: Описывают взаимодействие между пользователями и системой, а также последовательность действий для достижения конкретных целей.
Use Case-диаграммы: Use Case-диаграмма является визуальной диаграммой, которая представляет отношения между актерами (пользователями, системами или внешними сущностями) и различными Use Case'ами (сценариями использования) системы. Она демонстрирует, как актеры взаимодействуют с системой для достижения определенных целей.
Use Case-сценарии: Use Case-сценарии представляют собой текстовое описание последовательности действий, которые пользователи выполняют для достижения конкретной цели в системе. Каждый Use Case-сценарий описывает взаимодействие пользователя и системы от начала до конца.
Пример Use Case Diagram:
Почему важны пользовательские требования
Требования подразделяются на уровни: сверху находятся бизнес-требования, из них выделяются пользовательские требования, а затем функциональные.
После определения бизнес-требований системный аналитик взаимодействует с заинтересованными лицами для уточнения пользовательских требований к будущей системе.
Выявление пользовательских требований поможет разработать систему, которая принесёт максимальную пользу конечным пользователям. Ориентация на пользовательские требования помогает команде разработки избежать ситуаций, при которых она создает ненужную функцию и тратит время зря.
Как зафиксировать пользовательские требования так, чтобы всем было понятно, что именно пользователь будет делать в системе и какие шаги ему для этого надо пройти? В этом помогут варианты использования, которые применяются для представления пользовательских требований.
Вариант использования (Use Case) описывает взаимодействие между действующим лицом и системой для получения определенного значимого результата.
Действующее лицо, или актор / актёр - ключевая роль в описании вариантов использования. Это может быть человек или приложение, которое взаимодействует с системой для реализации одного из вариантов использования.
Выделить акторов участвующих в вариантах использования, помогут такие вопросы:
- Кто (или что) уведомляется, если что-то происходит внутри системы?
- Кто (или что) предоставляет системе информацию и сервисы?
- Кто (или что) помогает системе среагировать и выполнить задачу?
Варианты использования нацелены именно на взаимодействие пользователя и системы. Это значит, что их можно применить при разработке систем, где возможны различные сценарии её использования. Use Case не подойдут при анализе приложений для формирования отчётов или хранения каких-либо данных, поскольку в этом случае варианты использования ограничатся лишь несколькими простыми сценариями.
Благодаря пользовательским требованиям, представленным в виде вариантов использования, системным аналитикам проще сформулировать функциональные требования к системе, а значит, меньше риск упустить что-то важное.
Варианты использования могут быть представлены в графической форме или в виде таблицы.
Графическая форма вариантов использования
Use Case Diagram - нотация для моделирования вариантов использования системы пользователями. Она позволяет изучить требование, ответив на вопрос: «Как пользователь может воздействовать на систему?»
Use Case Diagram также называют диаграммой вариантов использования или диаграммой прецедентов. С её помощью можно получить высокоуровневое представление о том, как пользователь или другое приложение взаимодействует с системой. Для построения данной диаграммы используется нотация UML.
Диаграмма состоит из:
- Акторов / Актёров
- Вариантов использования
- Границ системы
- Связей между элементами
Рассмотрим простую диаграмму Use Case на примере интернет-магазина.
Изучив диаграмму, мы можем понять, как актор может взаимодействовать с нашей системой.
Как построить диаграмму Use Case
Актор
Первое, что нам необходимо сделать при построении диаграммы Use Case, - выделить акторов. То есть определить тех, кто будет пользоваться нашей системой. Если вернуться к примеру выше, у нас есть пользователь сайта, который на диаграмме изображается как человечек с подписью внизу.
Варианты использования
Следующим шагом нам необходимо выделить варианты использования. Для этого ответим на вопрос: «Что актор хочет делать в нашей системе?». В нашем примере он хочет заходить на сайт и иметь возможность оформлять заказ. На диаграмме варианты использования изображаются в форме овала, внутри которого написан вариант использования в формате «глагол + существительное». Пример:
Границы системы
Для более четкого понимания того, какие действия происходят внутри нашей системы, а какие - вне её, в диаграммах можно выделить границы системы. Они отображаются в виде прямоугольника.
Типы связей
Чтобы соединить акторов и варианты использования или определить, как разные варианты использования соотносятся друг с другом, в диаграмме Use Case выделяют различные типы связей.
Связь ассоциации
Эта связь обозначается на диаграмме обычной линией без стрелки. С её помощью мы можем понять, с каким вариантом использования связан конкретный актор. Один вариант использования может быть связан с несколькими акторами. Важно учитывать, что связь ассоциации не используется для соединения между собой двух и более акторов, а также двух и более вариантов использования.
В нашем примере актор связан с двумя вариантами использования.
Связь обобщения
Эта связь обозначается на диаграмме стрелкой с пустым наконечником и направляется от частного к общему. Стрелка может объединять как акторов, так и варианты использования по какому-либо признаку. Важно понимать, что связь обобщения между вариантами использования подразумевает, что дочерний вариант использования содержит все атрибуты и шаги из родительского варианта использования.
Посмотрим на примере, как ребёнка и взрослого (акторов) можно обобщить до пользователя сайта.
(!)
Примечание - обобщать акторов смысла нет, так как в любом случае "Взрослый" и "Ребенок" с точки зрения системы будут "Пользователями сайта", а такое обобщение на диаграмме снижает наглядность диаграммы. Весь смысл диаграмм в том, что они наглядные
(!)
Варианты использования «купить персик» и «купить нектарин» можно обобщить до простого варианта «купить фрукты».
Связь включения
Связь обозначается пунктирной стрелкой с подписью include. Связь показывает, что вариант использования включает в себя другие варианты. Стрелка направлена от одного варианта использования на те варианты использования, которые включаются в него.
При просмотре своего профиля актор может увидеть личную информацию, адреса доставок и сохранённые банковские карты.
Связь расширения
Связь обозначается пунктирной стрелкой с подписью extend. Стрелка показывает, что один вариант использования опционально может расширять другой. В связи включения один вариант использования обязательно включается в другой, в связи расширения это необязательно.
Актор хочет купить продукты. Скорее всего, на кассе ему предложат купить пакет, товары по акции, что расширит список покупок актора. Важно понимать, что эти опции могут и не предложить, то есть такие варианты использования необязательны.
Use Case Scenario - табличная форма вариантов использования
Иногда лишь определения вариантов использования, как представлено в диаграмме Use Case, недостаточно. В таких случаях приходится умение представлять варианты использования в табличной форме, которая позволит разобраться в том, что происходит внутри одного варианта использования.
Табличная форма фокусируется на детальном рассмотрении последовательности действий, которая описывает взаимодействия актора и системы в рамках одного варианта использования (или сценария).
Среди вариантов использования существует один основной сценарий, остальные называются альтернативными. Основной сценарий показывает, что происходит, если всё идёт правильно и актор достигает конечной цели (sunny flow / happy path). Такой сценарий воспроизводится чаще всего.
Альтернативный сценарий показывает, что происходит, если что-то пошло не так и основной сценарий не воспроизводится. Такой вариант тоже может привести к успеху, при этом альтернативный сценарий представляет реже встречающиеся вариации последовательности действий в варианте использования. Основной сценарий может перейти в альтернативный, а затем вернуться обратно (или нет) в основной и успешно завершиться.
Табличная форма может состоять из:
- Идентификатор сценария - “UC_[платформа][действие][цифра]”
- Наименование варианта использования
- Контекст использования
- Область действия
- Уровень
- Основное действующее лицо (основной актор)
- Участники (дополнительные действующие лица)
- Предусловия
- Минимальные гарантии успеха
- Гарантии успеха (Постусловия)
- Триггер
- Описание (основной сценарий)
- Расширения (альтернативные сценарии)
- Изменения в технологиях и данных
Рассмотрев две формы представления вариантов использования, можно сделать вывод, что одно не заменяет другое, а таблица расширяет понимание диаграммы.
Use Case Scenario - это описание того, как пользователь (или другая система) взаимодействует с программой или сервисом для достижения конкретной цели. Это как пошаговый рассказ о том, что делает пользователь и как система реагирует.
Одна из возможных структур текстового сценария использования:
| Поле | Описание |
|---|---|
| Идентификатор UC | Уникальный идентификатор, чтобы ссылаться на UC и удобно искать UC по реестру UC UC_mobile_auth |
| Заголовок | Название варианта использования Положить товар в корзину |
| Область применения | Мобильное приложение интернет-магазина |
| Участники | Основное действующее лицо (актор/актёр) и все дополнительные участники. Любой пользователь мобильного приложения |
| Предусловия | В каком состоянии должен находиться каждый участник юзкейса, чтобы ситуация произошла. Условие, которое должно быть выполнено ДО начала основного потока. Пользователь должен быть авторизован. Пользователь находится на детальной странице товара |
| Триггеры | Действие, которое приводит к началу выполнения основного потока. Пользователь попал на страницу через нажатие на баннер |
| Основной поток | «Диалог» актора и системы - порядок действий и реакций на действия. Всегда начинается с действия главного актора. Действия записываются в активном залоге с прямым порядком слов. «Пользователь выбирает строку в таблице A». Полезные вопросы для уточнения формулировки действия: 1. Кто именно? 2. Что именно? 3. Когда именно? 4. Где именно? Основной поток это так называемый sunny flow. Тут прописывается успешный “базовый” сценарий - тут ошибок нет, вся обработка ошибок, ветвления и исключения описываются в альтернативных потоках |
| Альтернативные потоки | Обрабатывают ошибки, ветвления, прерывания, исключения основного потока. Могут быть описаны отдельно или в конце описания UC. Для поиска АП нужно на каждом шаге ОП искать возможные альтернативные действия, ошибки, а также прерывания, которые могут случиться как на данном шаге ОП, так и в любой момент. Количество альтернативных потоков необходимо свести к минимуму: - вариант 1: выбрать только самые важные альтернативные потоки - вариант 2: для группы похожих альтернативных потоков документировать только один, как образец, а для остальных по необходимости, добавить примечания об отличиях |
| Постусловия | Состояние системы после окончания выполнения основного потока (и варианта использования соответственно) Должны выполняться обязательно. |
| Специальные требования | Текстовое описание требований, не отраженных в сценарии. Чаще всего это нефункциональные требования |
При создании UCS (сценариев использования) необходимо учесть следующее:
- Варианты использования: какую функциональность хотим смоделировать?
- Действующие лица: кто будет взаимодействовать с системой?
- Потоки: каков порядок шагов в каждом варианте использования?
- Взаимосвязи: как потоки использования связаны друг с другом?
Советы и рекомендации по созданию Use Case (UC)
- Сценарии вариантов использования должны быть простыми и понятными
- Сценарии вариантов использования не должны быть расплывчатыми. Покажи сценарии другим людям, чтобы убедиться, что не пропустили ни одного шага
- Сценарии использования должны быть сфокусированы на пользователе и его взаимодействии с системой
- Используй стандартную нотацию - UML для UC диаграмм, таблицы для UC сценариев